Synopsys Roundtable: Hard lessons to be learnt from the SolarWinds attack

On Dec 11, 2020, the SolarWinds Orion security breach, a.k.a. SUNBURST, impacted numerous U.S. government agencies, business customers and consulting firms. Hackers managed to plant a backdoor in the SolarWinds system which is widely used across both Government and Private organisations. The malicious software looked legitimate because it was signed using the SolarWinds certificate. This is known as a supply-chain attack because it infects software as it’s under assembly. The compromised update has had a sweeping impact, the scale of which keeps growing as new information emerges.

The breach – large scale impact

18,000 is a staggering number of customers who accounted for the toll of a meticulously planned attack that resulted from a SolarWinds hack during the period of March-December 2020. SolarWinds is an information technology management firm based in Austin, Texas who had led the US market share for their network management system software (NMS) since 2017. Their NMS, Orion that monitors and analyses operations, helps businesses manage their systems, networks and infrastructures. As reported to the SEC (Securities and Exchange Commission), around 18,000 of their customers downloaded the March update of Orion which had been compromised. The list includes 80% of the Fortune 500 companies and more concerningly United States government organisations like the Treasury Department, Commerce Department, Department of Homeland Security, etc. to name a few.

While investigations are still underway, the full extent of the impact is yet to be deciphered. The hackers got into the code-building environment and, in a very sophisticated way, were able to insert a backdoor into SolarWinds’ Orion network management software code. The most concerning thing is that even the Department of Defense, Microsoft or Cisco were not able to catch the breach and was eventually uncovered by a cybersecurity company FireEye, who reported to SolarWinds that their code was tainted. While the US government called the rogue group Advanced Persistent Threat 29, or APT29, they also go by the name ‘Cozy Bear’, but these are only still speculations as there hasn’t been solid proof of the identity of the hackers yet. In fact, even though the sophistication of these attacks is beyond comprehension, like in the recent Twitter fiasco, where surprisingly the culprits turned out to be bunch of teenagers, security hacking has almost become ‘child’s play’ for some and rebounding nightmares for corporations.

Vulnerable third-party products are providing attackers with a foothold and hence the labelling of this as ‘supply chain attack’ which brings the third-party software into the spotlight with this incident. It is also clear now that the attackers more often than not, remain undetected within the network and probably got in using the gap of a weak password. FireEye first got whiff of the breach when a login into a mobile device was reported from an unrecognised location and credential. This demonstrated a simple use of MFA that caught one of the most destructive attacks ever seen. What hasn’t been estimated yet is the extent of the damage or the breadth of the lateral movement as they left no artifacts from their code and effectively covered their tracks to perfection.

Protect thy Crown Jewels

“From a risk management standpoint, it is of paramount importance to identify your crown jewels and segregate the home environment into different pieces and build really strong gates around it” says Ashwath Reddy, Principal Consultant, Synopsys Software Integrity Group (SIG)”. Reddy also notes the importance of Vendor management by understanding their security requirements (pen test or source code review) and reviewing and negotiating on the contracts with them. As containers become a common method of packaging and deploying apps, securing them have become a big priority for DevOps engineers. Thus, scanning and audit of images and containers for bugs and vulnerabilities has become crucial for DevSecOps who play an important role in adding security in the DevOps processes.

With increasing pressure to build and release software faster than ever before, security controls that should be addressed early in the software development life cycle (SDLC) are often not addressed until it’s far too late.

Failing to build security controls into applications in the design phase causes:

• Inadequate protection against malicious attackers
• Weaker defences against outside and inside threats
• Increased possibility of damaging threat events like data breaches

By creating threat models for external assets and components like APIs, cloud infrastructure, and hosted data centres, you can begin to anticipate new forms of attacks and prioritise application risks by factors such as threats by likelihood. An architectural risk assessment dives deeper by mapping and analysing the correlation between threats, internal assets, and design structure to expose system flaws scattered throughout your application’s architecture. Examining your application’s design through threat modelling and architectural risk assessments helps to uncover design flaws early in the SDLC that traditional testing methods often miss.

In today’s threat landscape, it is usually a matter of ‘when’, to find out about the breach that occurred within the network and in many instances the organisation only hasn’t discovered it yet despite deploying prevention strategies and technology. This calls for a change in mindset to an ‘assume breach’ mentality than a prevention focussed one. It guides design decisions, security investments and operational security practices. ‘Assume Breach’ treats both internal and external (network, identities and services) as not secure and probably already compromised.

The total impact of a potential security event is usually measured by the blast radius. To have strategies in place for isolation, segmentation and least privilege in IAM are crucial in preventing further lateral movement post breach. The blast radius is usually larger in a cloud environment resulting in catastrophic damage to businesses. At the dawn of the COVID-19 crisis, there was a massive haste in businesses moving to the cloud and while the cloud providers advertise strong compliance and security measures, security is a mutual/shared responsibility. Rushing into cloud migrations and spinning up servers recklessly, exposes companies to a host of threats like insecure interfaces, platform misconfigurations, unauthorised access and account jacking to name a few.

Trust Zero to Sleep Better

John Kindervag, principal analyst at Forrester Research Inc. created in 2010, the now famous model of Zero Trust Network or Zero Trust Architecture. There is an imminent shift in CIOs and CISO’s today to evolve from the ‘protect the perimeter’ mindset while realising that most of the worst attacks are activated once the attacker gains access inside the networks and moves internally without resistance.

Cybersecurity Ventures¹ media notes several eye-opening statistics which puts into perspective the importance of security in the new normal. Cybercrime damage costs are predicted to hit $6 trillion annually by 2021 and ransomware attacks on healthcare organisations — often called the No. 1 cyber-attacked industry — expected to quadruple. Cybersecurity Ventures expects that a business will fall victim to a ransomware attack every 11 seconds by 2021, up from every 14 seconds in 2019. This makes ransomware the fastest growing type of cybercrime. The recent attacks by SolarWinds and FireEye underscores that no organisation is immune to threats and attacks. Attackers are looking for ways to evade IT attention, bypass defences, and exploit emerging weaknesses. The fallout from this attack will likely capture a large proportion of attention of governments and Fortune 500 cybersecurity teams in 2021 and will result in rollout of more stringent cybersecurity policies especially targeting supply chain vulnerabilities.

With no internal or external users or machines being automatically trusted, the Zero Trust network assumes that there are attackers both within and outside the network. One way of ensuring this is by the least-privilege access to users to give them only sufficient access to complete their pertinent task and no more, thus minimising their exposure to sensitive areas of the network. MFA (Multi-factor authentication) has been proving to prevent attackers by needing to use multiple devices to login and hence providing added security. Controls on device access enables minimising the threat surface by authorising every device, every time access is required.

AppSec best practices and tools

As we witness exponential growth in software applications, the security threats have shown an equal rise in numbers. This calls for effective and efficient security measures by using best practices and tools. The most common tools are:

• SAST: Also known as “white-box testing”, Static Application Security Testing (SAST) is a type of software security vulnerability testing that can identify security vulnerabilities early in development.
• DAST: Also known as “black-box testing”, Dynamic Application Security Testing (DAST) identifies security errors, run-time, and environment-related issues later in the development cycle.

For over a decade, the Building Security In Maturity Model (BSIMM) report² has provided a measuring stick and blueprint to help CISOs and security teams compare the maturity of their programs against those of their peers. Measurements and benchmark data are derived from organisations participating in the BSIMM, so it provides a direct line of sight into the real AppSec program strategies being practiced today. Application security isn’t simply about deploying tools and running tests. It’s about aligning people, process, and technology to address application security risks holistically.

Synopsys had recently published the Complete Application Security Checklist³

1. Eliminate vulnerabilities before applications go into production. To address application security before development is complete, it’s essential to build security into your development teams (people), processes, and tools (technology).

2. Address security in architecture, design, and open source and third-party components. If you’re only checking for bugs in your proprietary code or running penetration tests against your system, you’re likely missing a substantial number of the vulnerabilities in your software.

3. Adopt security tools that integrate into the developer’s environment. One way to do this is with an IDE plugin, which lets developers see the results of security tests directly in the IDE as they work on their code.

4. Build an “AppSec toolbelt” that brings together the solutions needed to address your risks. An effective AppSec toolbelt should include integrated solutions that address application security risks end-to-end, providing analysis of vulnerabilities in proprietary code, open-source components, and runtime configuration and behaviour.

5. Analyse your application security risk profile so you can focus your efforts. Knowing what’s important requires a team of experienced security experts to analyse an application portfolio quickly and effectively and identify the specific risk profile for each app and its environment.

6. Develop a program to raise the level of AppSec competency in your organisation. Be sure you’re focusing on the actions that will have the biggest positive impact on your software security program at the least possible cost.

7. Provide your staff with sufficient training in AppSec risks and skills. High-quality training solutions can help security teams raise the level of application security skills in their organisations.

8. Augment internal staff to address skill and resource gaps. Find a trusted partner that can provide on-demand expert testing, optimise resource allocation, and cost-effectively ensure complete testing coverage of your portfolio.

9. Make sure you understand your cloud security provider’s risks and controls. It’s essential that your security, development, and operations teams know how to handle the new security risks that emerge as you migrate to the cloud.

10. Develop a structured plan to coordinate security initiative improvements with cloud migration. Once you fully understand the risks, you can create a roadmap for your cloud migration to ensure all teams are in alignment and your priorities are clear.

11. Establish security blueprints outlining cloud security best practices. Security blueprints can help guide development teams and systems integrators in building and deploying cloud applications more securely.

In the sojourn around the security jungle, having a road map is a key to successful navigation. While Open source or in-house developed apps are on the upward trajectory, the attacks exploiting vulnerabilities in open-source code libraries have also increased. The choices are many and for companies, the faster and sooner in the software development process they can find and fix security issues, the safer enterprises will be.

References:

1. Cybersecurity Ventures¹ – Cybercrime magazine stats
2. (BSIMM) report^{2 –} Building Security in Maturity Model report
3. Complete Application Security Checklist³ – Synopsys checklist for AppSec